The rapid evolution of computer and communication technologies coupled with the robust economies of the 1980s and 1990s resulted in unprecedented growth in the information technology (“IT”) field. During this period, the need to establish a competitive advantage drove companies to faster and faster rates of change to support new product offerings and expanded services. As a result of these market pressures and time constraints, most companies elected to support new products and services by adding additional back office systems. However, due to the lack of mature integration technologies, the new systems were connected to the existing IT systems by making direct connections to the software routines already in use. The vulnerability of this design is that a change in one system produces a “ripple effect” change in every system it connects with. Over time, this incremental stacking of software systems can result in an integration ceiling. That is, at a certain point, more effort is spent on the connections than on new functionality and further expansion becomes cost prohibitive.
In the late 1990s, new integration technologies emerged that made it possible to “loosely couple” applications so that systems are no longer directly connected. Thus, changes in one system would not cause a ripple effect in any other systems. The most notable of these technologies are Message Oriented Middleware (“MOM”), Publish and Subscribe messaging, and Object Request Brokers (“ORBs”). These technologies enabled companies to re-architect their conglomeration of systems into an architecture that allows them to expand in a cost-effective manner. Technologies such as these that address the problem of integrating existing systems with new systems in an organized, efficient, and economically scaleable manner can be referred to collectively as enterprise application integration (“EAI”) technologies.
An integrated enterprise may have any number of applications which interact with one or more shared databases (also referred to as an integrated information store (“IIS”)) of the integrated enterprise through a data access layer (“DAL”). Among other things, interface control documents (“ICDs”) for an integrated enterprise describes all of the application-to-database operations taking place within the integrated enterprise. An interaction with a database of an integrated enterprise is typically in the form of a “call” comprised of a first (or “logical operation name”) portion, a second (or “logical data aggregate name”) portion and a third (or “data attribute”) portion. The logical operation name portion of the call describes the type of application-database operation to be conducted, the logical data aggregate name portion of the call describes the name of the data to which the operation is applied and the data attribute portion of the call is comprised of one or more data attributes, each of which describes a discrete characteristic of the data involved in the application-database operation.
Application-database operations may be divided into two types of operations—those that produce data and those that consume data. As defined herein, data producing operations are those operations which involve data being written to a database. Data consuming operations, on the other hand, are herein defined as those operations which involve data being read from a database. Many problems in application-database operations arise when a system designer fails to ensure that a correspondence exists between the data produced and the data consumed. In other words, application-database operations which involve consuming data which was never produced (hereafter referred to as a “producer exception”) or producing data which is never consumed (hereafter referred to as a “consumer exception”) should be avoided. Of the two, the former is a more serious problem. Since data cannot be consumed before it is produced, a producer exception causes an error in the system. Conversely, while a consumer exception does not cause a system error, since there is no reason to produce data which is never consumed, a consumer exception unnecessarily wastes system resources.
Errors such as these can only be identified through a detailed manual examination of the ICD documents which model an enterprise. Such a task can be quite difficult, however, in view of how ICD documents are structured. For example, an ICD document constructed using “Rational Rose”, a unified modeling language (“UML”) modeling tool commercially available through Rational Software Corporation of Cupertino, Calif. and Lexington, Mass., is configured hierarchically in the manner illustrated in FIG. 1.
As may be seen in FIG. 1, an ICD document 1 is comprised of plural classes, one of which is shown in FIG. 1 as class 2. Each class models information and associated behavior which must be stored. For example, the class 2 may be a sequence diagram forming part of the ICD document 1. The behavior of the class 2 is comprised of one or more operations. By way of example, the behavior of the class 2 is shown as being comprised of first and second operations 3 and 4, each of which are operations conducted by the class 2. In turn, each operation 3 and 4 includes one or more data attributes. Again, by way of example, the operation 3 includes first and second data attributes 5 and 6 while the operation 4 includes first and second data attributes 7 and 8. Each data attribute 5 and 6, 7 and 8 describes an element of the data involved in the corresponding operation 3, 4 which the operation is conducted. However, as the number of data attributes associated with each operation and the number of operations conducted by each class increases beyond the simple example illustrated in FIG. 1, the task of locating two occurrences of an attribute, one associated with a data producing operation and the other associated with a data consuming operation becomes increasingly difficult. It is, therefore, the object of this invention to provide a tool which simplifies this task.